<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1" >
<title>Xsemantics Syntax</title>

<link href="book.css" rel="stylesheet" type="text/css">
<link href="code.css" rel="stylesheet" type="text/css">
<link rel="home" href="00-Main.html" title="">
</head>
<body>
<a name="Syntax"></a>
<h1>Xsemantics Syntax</h1>
<p>
Here we describe the syntax of Xsemantics. You may also
want to refer to <a href="Examples.html#Examples" title="Go to &quot;Examples&quot;" >section Examples</a> for better understanding the syntax
of judgments, rules, etc.
</p>
<a name="Imports"></a>
<h2>Imports</h2>
<p>
You can specify <span class="inlinecode"><span class="keyword">import</span></span>s like in Java (you don&apos;t need the terminating <span class="inlinecode">;</span>),
possibly with a terminating <span class="inlinecode">*</span> in order to import all the classes of that
Java package (the use of wildcard imports is deprecated though).
</p>
<p>
Since version 1.3.0 (i.e., after the move to Xbase 2.4) you can also specify
<em>static imports</em> (wildcard can be used for static imports); Since version 1.4.3
imports can be specified before defining the <span class="inlinecode"><span class="keyword">system</span></span>; this should
be the preferred way (for backward compatibility, imports can also be specified
after the system definition, but it is better not to mix the two forms). 
</p>
<p>
For example:
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">import</span>&nbsp;<span class="keyword">static</span>&nbsp;org.eclipse.xtext.EcoreUtil2.*<br/>
<br/>
...<br/>
<br/>
<span class="comment">//&nbsp;simply&nbsp;use,&nbsp;for&nbsp;example<br/>
</span>getContainerOfType(o,&nbsp;<span class="keyword">typeof</span>(EClass))<br/>
<span class="comment">//&nbsp;instead&nbsp;of<br/>
</span>EcoreUtil2.getContainerOfType(o,&nbsp;<span class="keyword">typeof</span>(EClass))<br/>
</p>
</div>
</div>
</p>
<p>
You can also specify <em>static extension imports</em> (you may know such feature
from Xtend, and it has exactly the same semantics), so that you can
use all the imported methods as <em>extension methods</em>; for example
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">import</span>&nbsp;<span class="keyword">static</span>&nbsp;<span class="keyword">extension</span>&nbsp;org.eclipse.xtext.EcoreUtil2.*<br/>
<br/>
...<br/>
<br/>
<span class="comment">//&nbsp;use&nbsp;EcoreUtil2&nbsp;static&nbsp;methods&nbsp;as&nbsp;extension&nbsp;methods<br/>
</span>o.getContainerOfType(<span class="keyword">typeof</span>(EClass))<br/>
</p>
</div>
</div>
</p>
<p>
Content assist for Java types is provided, which automatically
inserts the corresponding import statement.
</p>
<p>
The menu <em>"Organize Imports"</em> is also available for Xsemantics files.
</p>
<a name="Copyright"></a>
<h2>Copyright</h2>
<p>
A copyright header string can be specified that will be added
in the generated Java code as a header comment:
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">copyright</span>&nbsp;<span class="string">"(C)&nbsp;This&nbsp;is&nbsp;a&nbsp;test\ncopyright&nbsp;header."</span><br/>
</p>
</div>
</div>
</p>
<a name="Fields"></a>
<h2>Fields</h2>
<p>
You can then specify <em>fields</em> in an Xsemantics system, using basically the
same syntax of Xbase variable declarations, here are some examples:
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">var</span>&nbsp;MyClass&nbsp;foo&nbsp;<span class="comment">//&nbsp;non&nbsp;final&nbsp;field<br/>
</span><br/>
<span class="comment">//&nbsp;for&nbsp;final&nbsp;field&nbsp;you&nbsp;must&nbsp;specify&nbsp;an&nbsp;initialization&nbsp;expression<br/>
</span><span class="keyword">val</span>&nbsp;MyOtherUtilityClass&nbsp;bar&nbsp;=&nbsp;<span class="keyword">new</span>&nbsp;MyOtherUtilityClass()<br/>
<br/>
<span class="comment">//&nbsp;the&nbsp;type&nbsp;can&nbsp;be&nbsp;omitted:&nbsp;it&nbsp;will&nbsp;be&nbsp;inferred&nbsp;from&nbsp;the&nbsp;initialization&nbsp;expression<br/>
</span><span class="comment">//&nbsp;(in&nbsp;that&nbsp;case,&nbsp;the&nbsp;initialization&nbsp;expression&nbsp;is&nbsp;mandatory)<br/>
</span><span class="keyword">val</span>&nbsp;bar2&nbsp;=&nbsp;<span class="keyword">new</span>&nbsp;MyOtherUtilityClass()<br/>
</p>
</div>
</div>
</p>
<p>
Fields can also be declared as <span class="inlinecode"><span class="keyword">extension</span></span>
(you may know such feature
from Xtend, and it has exactly the same semantics), so that you can
use all the methods of the corresponding type as <em>extension methods</em>; for example,
assuming this class
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">import</span>&nbsp;java.util.List;<br/>
<br/>
<span class="keyword">public</span>&nbsp;<span class="keyword">class</span>&nbsp;MyExtensions&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">public</span>&nbsp;<span class="keyword">void</span>&nbsp;printList(List&lt;Object&gt;&nbsp;l)&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;...<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;}<br/>
}<br/>
</p>
</div>
</div>
</p>
<p>
We can write
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="comment">/*&nbsp;a&nbsp;utility&nbsp;field&nbsp;*/</span><br/>
<span class="keyword">var</span>&nbsp;<span class="keyword">extension</span>&nbsp;MyExtensions&nbsp;myextensions&nbsp;=&nbsp;<span class="keyword">new</span>&nbsp;MyExtensions<br/>
<br/>
...<br/>
<br/>
<span class="keyword">rule</span>&nbsp;EObjectEClass<br/>
&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;EObject&nbsp;o&nbsp;:&nbsp;EClass&nbsp;c<br/>
<span class="keyword">from</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">val</span>&nbsp;list&nbsp;=&nbsp;newArrayList()<br/>
&nbsp;&nbsp;&nbsp;&nbsp;list.printList&nbsp;<span class="comment">//&nbsp;printList&nbsp;comes&nbsp;from&nbsp;MyExtensions<br/>
</span>}<br/>
</p>
</div>
</div>
</p>
<p>
Fields can be annotated with Java annotations, e.g.,
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
@Inject<br/>
<span class="keyword">var</span>&nbsp;MyClass&nbsp;foo<br/>
</p>
</div>
</div>
</p>
<p>
As a shortcut for injected fields, you can declare <span class="inlinecode"><span class="keyword">inject</span></span> fields
(<span class="inlinecode"><span class="keyword">inject</span></span> fields can also be specified as <span class="inlinecode"><span class="keyword">extension</span></span> fields):
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">inject</span>&nbsp;MyClass&nbsp;foo<br/>
<span class="keyword">inject</span>&nbsp;<span class="keyword">extension</span>&nbsp;MyOtherUtilityClass&nbsp;bar<br/>
</p>
</div>
</div>
</p>
<p>
Remember that these will correspond to fields in the generated Java class
(<a href="XsemanticsSyntax.html#CodeGeneration" title="Go to &quot;Generated Code&quot;" >section CodeGeneration</a>),
that will be instantiated through Guice injection.
</p>
<p>
In particular,
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">inject</span>&nbsp;MyClass&nbsp;foo<br/>
</p>
</div>
</div>
</p>
<p>
can be seen as a shortcut for
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
@Inject<br/>
<span class="keyword">var</span>&nbsp;MyClass&nbsp;foo<br/>
</p>
</div>
</div>
</p>
<p>
NOTE: Until version 1.7.1, only <span class="inlinecode"><span class="keyword">inject</span></span> fields could be specified; the more general
syntax for field definition has been introduced in version 1.7.2.
</p>
<a name="Judgments"></a>
<h2>Judgments</h2>
<p>
Then, you have to declare the <em>judgments</em> of your system;
a judgment consists of
</p>
<p>
<ul>
	<li>
		a name, which has to be unique in the system;
	</li>
	<li>
		a <em>judgment symbol</em> that can be chosen from some predefined symbols;
	</li>
	<li>
		the <em>parameters</em> of the judgment; parameters of a judgments are separated by
			a <em>relation symbol</em> that can be chosen from some predefined symbols;
	</li>
</ul>
</p>
<p>
The parameters can be
</p>
<p>
<ul>
	<li>
		input parameters, in that case they are declared as Java parameters;
	</li>
	<li>
		output parameters, in that case you use the keyword <span class="inlinecode">output</span> followed
		by the Java type of the output parameter.
	</li>
</ul>
</p>
<p>
For instance, these are some examples of judgments, using the
classes from EMF Ecore, and other Java classes
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">system</span>&nbsp;my.test.System<br/>
<br/>
<span class="keyword">import</span>&nbsp;org.eclipse.emf.ecore.*<br/>
<span class="keyword">import</span>&nbsp;java.util.*<br/>
<br/>
<span class="keyword">judgments</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;type&nbsp;|-&nbsp;EObject&nbsp;obj&nbsp;:&nbsp;<span class="keyword">output</span>&nbsp;EClassifier<br/>
&nbsp;&nbsp;&nbsp;&nbsp;subtype&nbsp;|-&nbsp;EObject&nbsp;left&nbsp;&lt;:&nbsp;EObject&nbsp;right<br/>
&nbsp;&nbsp;&nbsp;&nbsp;interpret&nbsp;|-&nbsp;EObject&nbsp;exp&nbsp;~&gt;&nbsp;<span class="keyword">output</span>&nbsp;EObject<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;nonsense&nbsp;judgment,&nbsp;just&nbsp;a&nbsp;demo<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;foobar&nbsp;||-&nbsp;List&lt;EObject&gt;&nbsp;objects&nbsp;|&gt;&nbsp;<span class="keyword">output</span>&nbsp;String&nbsp;&lt;~&nbsp;EClass&nbsp;context<br/>
}<br/>
</p>
</div>
</div>
</p>
<p>
A judgment can have at least one input parameter, and at most three output
parameters (the latter limitation does not seem to have an impact, since
it is rare to want more than three ouput parameters, but of course, it is
easy to remove this limitation in case).
</p>
<p>
A judgment without output parameters is also called <em>predicate judgment</em>.
</p>
<p>
Once you declared the judgments of your system, you can start declaring the rules.
</p>
<p>
Each rule consists of
</p>
<p>
<ul>
	<li>
		a name, which has to be unique in the system;
	</li>
	<li>
		a <em>rule conclusion</em>;
	</li>
	<li>
		the <em>premises</em> of the rule;
	</li>
</ul>
</p>
<p>
The rule conclusion consists of
</p>
<p>
<ul>
	<li>
		the name of the <em>environment</em> of a rule (any identifier, see
		also <a href="XsemanticsSyntax.html#CodeGeneration" title="Go to &quot;Generated Code&quot;">the section about rule environment</a>);
	</li>
	<li>
		a <em>judgment symbol</em>;
	</li>
	<li>
		the <em>parameters</em> of the rules, which are separated by
		a <em>relation symbol</em> that can be chosen from some predefined symbols;
	</li>
</ul>
</p>
<p>
The things that make a rule belong to a specific judgment are, as you can
imagine, the judgment symbol, the relation symbols (which separate the parameters);
moreover the types of the parameters of a rule must be (Java) subtypes of the
corresponding types of the judgment (or exactly the same Java types).
Two rules belonging to the same judgment must differ for at least one input
parameter&apos;s type.
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">rule</span>&nbsp;MyFirstTypeRule&nbsp;&nbsp;<span class="comment">//&nbsp;a&nbsp;rule&nbsp;for&nbsp;the&nbsp;judgment&nbsp;&apos;type&apos;<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;EObject&nbsp;o&nbsp;:&nbsp;EClassifier&nbsp;result<br/>
<span class="keyword">from</span>&nbsp;{&nbsp;<span class="comment">/*&nbsp;premises&nbsp;*/</span>&nbsp;}<br/>
<br/>
<span class="keyword">rule</span>&nbsp;MySecondTypeRule&nbsp;&nbsp;<span class="comment">//&nbsp;a&nbsp;rule&nbsp;for&nbsp;the&nbsp;judgment&nbsp;&apos;type&apos;<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;OK&nbsp;since&nbsp;EClass&nbsp;is&nbsp;a&nbsp;subclass&nbsp;of&nbsp;EObject<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;and&nbsp;EClass&nbsp;extends&nbsp;EClassifier<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;EClass&nbsp;o&nbsp;:&nbsp;EClass&nbsp;result<br/>
<span class="keyword">from</span>&nbsp;{&nbsp;<span class="comment">/*&nbsp;premises&nbsp;*/</span>&nbsp;}<br/>
<br/>
<span class="keyword">rule</span>&nbsp;MyFirstWrongTypeRule&nbsp;&nbsp;<span class="comment">//&nbsp;a&nbsp;rule&nbsp;for&nbsp;the&nbsp;judgment&nbsp;&apos;type&apos;<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;ERROR:&nbsp;Notifier&nbsp;is&nbsp;not&nbsp;a&nbsp;subtype&nbsp;of&nbsp;EObject<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;Notifier&nbsp;n&nbsp;:&nbsp;EClass&nbsp;result<br/>
<span class="keyword">from</span>&nbsp;{&nbsp;<span class="comment">/*&nbsp;premises&nbsp;*/</span>&nbsp;}<br/>
<br/>
<span class="keyword">rule</span>&nbsp;MySecondWrongTypeRule&nbsp;&nbsp;<span class="comment">//&nbsp;a&nbsp;rule&nbsp;for&nbsp;the&nbsp;judgment&nbsp;&apos;type&apos;<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;ERROR:&nbsp;it&nbsp;differs&nbsp;from&nbsp;MyFirstTypeRule&nbsp;only&nbsp;for&nbsp;the<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;output&nbsp;parameter&nbsp;type:&nbsp;EClassImpl<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;EObject&nbsp;o&nbsp;:&nbsp;EClass&nbsp;result<br/>
<span class="keyword">from</span>&nbsp;{&nbsp;<span class="comment">/*&nbsp;premises&nbsp;*/</span>&nbsp;}<br/>
<br/>
<span class="keyword">rule</span>&nbsp;MyFirstSubtypeRule&nbsp;&nbsp;<span class="comment">//&nbsp;a&nbsp;rule&nbsp;for&nbsp;the&nbsp;judgment&nbsp;&apos;subtype&apos;<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;EObject&nbsp;o1&nbsp;&lt;:&nbsp;EObject&nbsp;o2<br/>
<span class="keyword">from</span>&nbsp;{&nbsp;<span class="comment">/*&nbsp;premises&nbsp;*/</span>&nbsp;}<br/>
<br/>
<span class="keyword">rule</span>&nbsp;MySecondSubtypeRule&nbsp;&nbsp;<span class="comment">//&nbsp;a&nbsp;rule&nbsp;for&nbsp;the&nbsp;judgment&nbsp;&apos;subtype&apos;<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;EClass&nbsp;c1&nbsp;&lt;:&nbsp;EClass&nbsp;c2<br/>
<span class="keyword">from</span>&nbsp;{&nbsp;<span class="comment">/*&nbsp;premises&nbsp;*/</span>&nbsp;}<br/>
<br/>
<span class="keyword">rule</span>&nbsp;MyThirdSubtypeRule&nbsp;&nbsp;<span class="comment">//&nbsp;a&nbsp;rule&nbsp;for&nbsp;the&nbsp;judgment&nbsp;&apos;subtype&apos;<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;EObject&nbsp;o1&nbsp;&lt;:&nbsp;EClass&nbsp;c2<br/>
<span class="keyword">from</span>&nbsp;{&nbsp;<span class="comment">/*&nbsp;premises&nbsp;*/</span>&nbsp;}<br/>
</p>
</div>
</div>
</p>
<p>
The premises of a rule which are specified in a <span class="inlinecode">from</span> block can be
any Xbase expression, or a <em>rule invocation</em> (see also <a href="XsemanticsSyntax.html#RuleInvocations" title="Go to &quot;Rule Invocations&quot;" >section RuleInvocations</a>).
If you think of a rule
declaration as a function declaration, then a rule invocation corresponds
to function invocation, thus you must specify the environment to pass
to the rule, and the arguments, both input and output arguments.
</p>
<p>
At runtime, the system will select the most appropriate rule according
to the runtime types of the passed argument (similar to
<em>polymorphic dispatch</em> mechanism).
</p>
<p>
In the premises you can assign values to the output parameters; and
when you invoke another rule, upon return, the output arguments will have
the values assigned in the invoked rule.
</p>
<p>
If one of the premises fails, then the whole rule will fail, and in turn
all the stack of rule invocation will fail.  If the premise is a boolean
expression, it will fail if the expression evaluates to false
(see also <a href="XsemanticsSyntax.html#CodeGeneration" title="Go to &quot;Generated Code&quot;">the section about boolean expressions</a> for
a more detailed explanation).  If the premise is a rule invocation,
it will fail if the invoked rule fails.
</p>
<p>
For instance, consider these implementations:
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">rule</span>&nbsp;MyFirstTypeRule&nbsp;&nbsp;<span class="comment">//&nbsp;a&nbsp;rule&nbsp;for&nbsp;the&nbsp;judgment&nbsp;&apos;type&apos;<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;EObject&nbsp;o&nbsp;:&nbsp;EClassifier&nbsp;result<br/>
<span class="keyword">from</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;o.eClass&nbsp;!=&nbsp;<span class="keyword">null</span><br/>
&nbsp;&nbsp;&nbsp;&nbsp;result&nbsp;=&nbsp;o.eClass<br/>
}<br/>
</p>
</div>
</div>
</p>
<p>
This rules requires that the feature <span class="inlinecode">eClass</span> of the passed <span class="inlinecode">EObject</span>
is not null, and the assigns the output parameter <span class="inlinecode">result</span>.
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">rule</span>&nbsp;MyFirstSubtypeRule&nbsp;&nbsp;<span class="comment">//&nbsp;a&nbsp;rule&nbsp;for&nbsp;the&nbsp;judgment&nbsp;&apos;subtype&apos;<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;EObject&nbsp;o1&nbsp;&lt;:&nbsp;EObject&nbsp;o2<br/>
<span class="keyword">from</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;o1&nbsp;&lt;:&nbsp;o2.eClass<br/>
}<br/>
</p>
</div>
</div>
</p>
<p>
This rule simply invokes another rule (in this case of the same judgment), passing
arguments (note that arguments can be any Xbase expression).
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">rule</span>&nbsp;MyThirdSubtypeRule&nbsp;&nbsp;<span class="comment">//&nbsp;a&nbsp;rule&nbsp;for&nbsp;the&nbsp;judgment&nbsp;&apos;subtype&apos;<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;EObject&nbsp;o1&nbsp;&lt;:&nbsp;EClass&nbsp;c2<br/>
<span class="keyword">from</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">var</span>&nbsp;EClass&nbsp;o1Type<br/>
&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;o1&nbsp;:&nbsp;o1Type<br/>
&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;o1Type&nbsp;&lt;:&nbsp;c2<br/>
}<br/>
</p>
</div>
</div>
</p>
<p>
This rule declares a local variable <span class="inlinecode">o1Type</span> which will be passed (as an output
argument) to a rule invocation (of another judgment: indeed rules can invoke
any other rule in the system, even belonging to a different judgment).
If the rule invocation succeeds, the local variable <span class="inlinecode">o1Type</span> will contain
the output result of the invoked rule.  Then, it will invoke another rule. 
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">rule</span>&nbsp;MySecondSubtypeRule&nbsp;&nbsp;<span class="comment">//&nbsp;a&nbsp;rule&nbsp;for&nbsp;the&nbsp;judgment&nbsp;&apos;subtype&apos;<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;EClass&nbsp;c1&nbsp;&lt;:&nbsp;EClass&nbsp;c2<br/>
<span class="keyword">from</span>&nbsp;{&nbsp;<span class="comment">/*&nbsp;premises&nbsp;*/</span>&nbsp;}<br/>
</p>
</div>
</div>
</p>
<p>
The rule conclusion elements corresponding to output parameters can also
be Xbase expressions; for instance we could have written (compare it with
the above code for the same rule).
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">rule</span>&nbsp;MyFirstTypeRule&nbsp;&nbsp;<span class="comment">//&nbsp;a&nbsp;rule&nbsp;for&nbsp;the&nbsp;judgment&nbsp;&apos;type&apos;<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;EObject&nbsp;o&nbsp;:&nbsp;o.eClass<br/>
<span class="keyword">from</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;o.eClass&nbsp;!=&nbsp;<span class="keyword">null</span><br/>
}<br/>
</p>
</div>
</div>
</p>
<p>
Moreover, if a rule does not require any premise, we can use a special
form of rules, called indeed <em>axiom</em>s
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="comment">//&nbsp;assuming&nbsp;we&nbsp;don&apos;t&nbsp;want&nbsp;to&nbsp;do&nbsp;any&nbsp;check<br/>
</span><span class="keyword">axiom</span>&nbsp;MyFirstTypeRule&nbsp;&nbsp;<span class="comment">//&nbsp;a&nbsp;rule&nbsp;for&nbsp;the&nbsp;judgment&nbsp;&apos;type&apos;<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;EObject&nbsp;o&nbsp;:&nbsp;o.eClass<br/>
</p>
</div>
</div>
</p>
<p>
.
</p>
<a name="Premises"></a>
<h2>Premises</h2>
<p>
The premises of an Xsemantics rule are considered in logical
and relation and are verified in the same order they are specified
in the block.
</p>
<a name="OrBlocks"></a>
<h3>Or Blocks</h3>
<p>
If we want to have premises (or blocks of premises) in logical <em>or</em> relation,
we can use the operator <span class="inlinecode">or</span>, which separates blocks of
premises; if (and only if) one of the premises of the first block fails, we
go to the second block, etc.
</p>
<a name="ExpressionsInPremises"></a>
<h3>Expressions in Premises</h3>
<p>
Xsemantics considers an Xbase expression as a boolean premise when it is
used as a statement, i.e., it is not the right expression in
an assignment, it is not the condition of a loop, it is not
the expression of an if, etc..  This holds
when the expression is used in a block, NOT in a closure block.
It is crucial to understand when a boolean expression is considered
as a premise since when a premise fails the whole rule fails.
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
...<br/>
<span class="keyword">from</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;a&nbsp;!=&nbsp;b&nbsp;<span class="comment">//&nbsp;boolean&nbsp;premise<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">var</span>&nbsp;c&nbsp;=&nbsp;(a&nbsp;!=&nbsp;b)&nbsp;<span class="comment">//&nbsp;NOT&nbsp;boolean&nbsp;premise<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">if</span>&nbsp;(a&nbsp;!=&nbsp;b)&nbsp;...&nbsp;<span class="comment">//&nbsp;NOT&nbsp;boolean&nbsp;premise<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;list.forEach&nbsp;[&nbsp;a&nbsp;!=&nbsp;b&nbsp;]&nbsp;<span class="comment">//&nbsp;NOT&nbsp;boolean&nbsp;premise<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;but,&nbsp;be&nbsp;careful:<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;list.forEach&nbsp;[&nbsp;<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;a&nbsp;!=&nbsp;b&nbsp;<span class="comment">//&nbsp;NOT&nbsp;boolean&nbsp;premise<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{&nbsp;a&nbsp;!=&nbsp;b&nbsp;}&nbsp;<span class="comment">//&nbsp;boolean&nbsp;premise<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;]&nbsp;<br/>
}<br/>
</p>
</div>
</div>
</p>
<a name="RuleInvocations"></a>
<h3>Rule Invocations</h3>
<p>
Rule invocations have already been introduced.  When rule invocations
concern predicate judgments, then they can be used also in contexts
where a boolean expression is expected.
</p>
<p>
Due to a (hopefully) temporary limitation of the Xsemantics parser, a rule
invocation is not an expression, thus you need to included it in a block.
</p>
<p>
For instance
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">if</span>&nbsp;(&nbsp;G&nbsp;|-&nbsp;t1&nbsp;&lt;:&nbsp;t2&nbsp;)&nbsp;{...&nbsp;<span class="comment">//&nbsp;SYNTAX&nbsp;ERROR<br/>
</span>
</p>
</div>
</div>
</p>
<p>
will issue an error, while this form is accepted:
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">if</span>&nbsp;(&nbsp;{G&nbsp;|-&nbsp;t1&nbsp;&lt;:&nbsp;t2}&nbsp;)&nbsp;{...&nbsp;<span class="comment">//&nbsp;OK,&nbsp;provided&nbsp;it&nbsp;refers&nbsp;to&nbsp;a&nbsp;predicate&nbsp;judgment<br/>
</span>
</p>
</div>
</div>
</p>
<p>
This limitation does not hold for lambda expressions, thus you
can simply write:
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
mytypes.forall[&nbsp;t&nbsp;|&nbsp;G&nbsp;|-&nbsp;t&nbsp;&lt;:&nbsp;MyType&nbsp;]<br/>
mytypes.exists[&nbsp;t&nbsp;|&nbsp;G&nbsp;|-&nbsp;t&nbsp;&lt;:&nbsp;MyType&nbsp;]<br/>
</p>
</div>
</div>
</p>
<p>
with the expected semantics ("for all elements of <span class="inlinecode">mytypes</span> the predicate
judgment must hold", similarly "does an element, satisfying the judgement, exist?").
</p>
<a name="Environment"></a>
<h3>Rule Environment</h3>
<p>
The concept of rule environment is taken from the type theory
(usually is denoted by the capital greek letter Gamma, that is why
we usually use the letter G for the examples, but you can use any
valid identifier).  It can be used to pass additional argument to rules.
If you want to be sure to pass an empty environment when invoking a rule
you can use the keyword <span class="inlinecode">empty</span>.
</p>
<p>
Furthermore, when passing an environment during a rule invocation, you
can specify additional <em>environment mapping</em>, using the syntax
<span class="inlinecode">key&nbsp;&lt;-&nbsp;value</span>, where you can use any Xbase expression;
you can also pass an environment with additional
mappings separated by a comma (or even build an environment from scratch
by specifyin all the mappings, still separated by a comma); for instance
<span class="inlinecode">G,&nbsp;x&nbsp;&lt;-&nbsp;<span class="string">&apos;foo&apos;</span>,&nbsp;y&nbsp;&lt;-&nbsp;10</span> or <span class="inlinecode">x&nbsp;&lt;-&nbsp;o.eClass,&nbsp;y&nbsp;&lt;-&nbsp;(o.eClass.name&nbsp;==&nbsp;<span class="string">&apos;foo&apos;</span>)</span>,
etc.
</p>
<p>
Note that when you pass an environment to a rule with additional mappings,
you actually pass a brand new environment, thus you will not modify the
current rule environment; if a mapping already exists in the current rule
environment, in the brand new environment (and only there) the existing mapping
will be overwritten.  Thus, the rule environment passed to a rule acts
in a stack manner.
</p>
<p>
Inside the premises, you can access the environment using the predefined
function <span class="inlinecode">env</span> with the following syntax
</p>
<p>
<span class="inlinecode">env(&lt;environment&nbsp;ID&gt;,&nbsp;&lt;key&gt;,&nbsp;&lt;expected&nbsp;Java&nbsp;type&gt;)</span>
</p>
<p>
for instance,
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">rule</span>&nbsp;MyFirstTypeRule&nbsp;&nbsp;<span class="comment">//&nbsp;a&nbsp;rule&nbsp;for&nbsp;the&nbsp;judgment&nbsp;&apos;type&apos;<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;EObject&nbsp;o&nbsp;:&nbsp;o.eClass<br/>
<span class="keyword">from</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;search&nbsp;for&nbsp;the&nbsp;mapping&nbsp;for&nbsp;o.eClass.name<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;and&nbsp;request&nbsp;it&nbsp;to&nbsp;be&nbsp;an&nbsp;instance&nbsp;of&nbsp;EClassifier<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">var</span>&nbsp;i&nbsp;=&nbsp;<span class="keyword">env</span>(G,&nbsp;o.eClass.name,&nbsp;EClassifier)<br/>
}<br/>
</p>
</div>
</div>
</p>
<p>
The <span class="inlinecode">env</span> function will fail (and make the rule fail) if no
mapping is found in the passed environment or if the mapped value
is not an instance of the specified Java class.
</p>
<p>
An example using the environment can be found in <a href="Expressions-example.html#MoreInvolvedExpressionsSystem" title="Go to &quot;A more involved Expressions System&quot;" >section MoreInvolvedExpressionsSystem</a>.
</p>
<a name="ErrorSpecification"></a>
<h3>Error Specification</h3>
<p>
When a premise of a rule fails, the whole chain of rule invocation
will fail, and the Java code generated by Xsemantics will generate
some informative errors, which by default, will contain a string
representation of the failed rules (or boolean expressions) which have
failed and a string representation of the arguments
(see also <a href="XsemanticsSyntax.html#StringRepresentation" title="Go to &quot;String Representation&quot;" >section StringRepresentation</a>).
</p>
<p>
However, usually you may want to customize error information genetated
by your system; you can do this with a custom <em>error specification</em>
which consists of
</p>
<p>
<ul>
	<li>
		<span class="inlinecode">error</span> and a string for the error
	</li>
	<li>
		<span class="inlinecode">source</span> and an <a class="jdoc" href="http://download.eclipse.org/modeling/emf/emf/javadoc/2.10.0/org/eclipse/emf/ecore/EObject.html" title="View JavaDoc"><abbr title="org.eclipse.emf.ecore.EObject" >EObject</abbr></a> <a class="srcLink" href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java" title="View Source Code" >(src)</a> specifying the object the error refers to
		(optional)
	</li>
	<li>
		<span class="inlinecode">feature</span> and an <a class="jdoc" href="http://download.eclipse.org/modeling/emf/emf/javadoc/2.10.0/org/eclipse/emf/ecore/EStructuralFeature.html" title="View JavaDoc"><abbr title="org.eclipse.emf.ecore.EStructuralFeature" >EStructuralFeature</abbr></a> <a class="srcLink" href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EStructuralFeature.java" title="View Source Code" >(src)</a> specifying the feature of the object 
		containing the error (optional)
	</li>
	<li>
		<span class="inlinecode">data</span> and any Java <a class="jdoc" href="http://docs.oracle.com/javase/8/docs/api/java/lang/Object.html" title="View JavaDoc"><abbr title="java.lang.Object" >Object</abbr></a> containing any additional information you want to
		store in the error (optional), <em>since version 1.7.0</em>
	</li>
</ul>
</p>
<p>
Error specifications can appear
</p>
<p>
<ul>
	<li>
		after a judgment, so that all rules belonging to that judgment
		will have errors generated according to the error specification
	</li>
	<li>
		after a rule conclusion, in that case this will have the precedence
		over the judgment&apos;s error specification
	</li>
	<li>
		after an explicit failure (<a href="XsemanticsSyntax.html#ExplicitFailure" title="Go to &quot;Explicit Failure&quot;" >section ExplicitFailure</a>)
	</li>
</ul>
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">judgments</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;type&nbsp;|-&nbsp;EObject&nbsp;obj&nbsp;:&nbsp;<span class="keyword">output</span>&nbsp;EClassifier<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">error</span>&nbsp;<span class="string">"cannot&nbsp;type&nbsp;"</span>&nbsp;+&nbsp;stringRep(obj)<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">source</span>&nbsp;obj<br/>
&nbsp;&nbsp;&nbsp;&nbsp;subtype&nbsp;|-&nbsp;EObject&nbsp;left&nbsp;&lt;:&nbsp;EObject&nbsp;right<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">error</span>&nbsp;stringRep(left)&nbsp;+&nbsp;<span class="string">"&nbsp;is&nbsp;not&nbsp;a&nbsp;subtype&nbsp;of&nbsp;"</span>&nbsp;+&nbsp;stringRep(right)<br/>
}<br/>
<br/>
<span class="keyword">rule</span>&nbsp;EClassCase<br/>
&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;EClass&nbsp;eClass&nbsp;:&nbsp;EClassifier&nbsp;result<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">error</span>&nbsp;<span class="string">"cannot&nbsp;type&nbsp;EClass&nbsp;"</span>&nbsp;+&nbsp;eClass.name<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">source</span>&nbsp;eClass<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">feature</span>&nbsp;EcorePackage::eINSTANCE.ENamedElement_Name<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">data</span>&nbsp;<span class="string">"Some&nbsp;additional&nbsp;data&nbsp;for&nbsp;the&nbsp;error"</span><br/>
<span class="keyword">from</span>&nbsp;{...}<br/>
</p>
</div>
</div>
</p>
<a name="ExplicitFailure"></a>
<h3>Explicit Failure</h3>
<p>
By using the keyword <span class="inlinecode">fail</span> you can implement an explicit failure
of the current premise block; After the <span class="inlinecode">fail</span> it would be good
to use also an error specification (<a href="XsemanticsSyntax.html#ErrorSpecification" title="Go to &quot;Error Specification&quot;" >section ErrorSpecification</a>).  Indeed,
explicit failure is really useful in conjunction with an error specification
(to specify an informative error) and an <span class="inlinecode">or</span>.  For instance,
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
o.eClass.EAllSuperTypes.contains(s)<br/>
<span class="keyword">or</span><br/>
<span class="keyword">fail</span>&nbsp;<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">error</span>&nbsp;<span class="string">"my&nbsp;custom&nbsp;error"</span><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">source</span>&nbsp;o<br/>
</p>
</div>
</div>
</p>
<a name="PreviousFailure"></a>
<h3>Accessing Previous Failure of an Or Block</h3>
<p>
Since version 1.7.0, in an <em>or</em> expression or block (see <a href="XsemanticsSyntax.html#OrBlocks" title="Go to &quot;Or Blocks&quot;" >section OrBlocks</a>) it is possible to access error information generated 
in the previous or block.  This can be achieved by using the implicit variable <span class="inlinecode">previousFailure</span>
which is of type <a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/RuleFailedException.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.RuleFailedException" >RuleFailedException</abbr></a> and can be assumed NOT <span class="inlinecode">null</span>.
Of course, such variable is available only in or blocks after the first one, unless the first or block
is itself contained in an outer or block.
</p>
<p>
This can be used together with all the other error features shown above; here&apos;s a simple
example
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
{<br/>
&nbsp;&nbsp;...<br/>
}&nbsp;<span class="keyword">or</span>&nbsp;{<br/>
&nbsp;&nbsp;...<br/>
&nbsp;&nbsp;<span class="keyword">fail</span><br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">error</span>&nbsp;<span class="string">"this&nbsp;error,&nbsp;caused&nbsp;by&nbsp;"</span>&nbsp;+&nbsp;previousFailure.message<br/>
</p>
</div>
</div>
</p>
<p>
If you inject in your system definition, as extension, a <a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/TraceUtils.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.TraceUtils" >TraceUtils</abbr></a> field
(see <a href="XsemanticsSyntax.html#Fields" title="Go to &quot;Fields&quot;" >section Fields</a>) you can also use it to process the previousFailure; for instance
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">inject</span>&nbsp;<span class="keyword">extension</span>&nbsp;TraceUtils&nbsp;traceUtils<br/>
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;...<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{...}<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">or</span><br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">fail</span><br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">error</span>&nbsp;<span class="string">"this&nbsp;is&nbsp;the&nbsp;previous&nbsp;error&nbsp;trace:&nbsp;"</span>&nbsp;+<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;previousFailure.failureTraceAsString<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">source</span>&nbsp;object<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;note&nbsp;the&nbsp;TraceUtils.failureTraceAsString<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;used&nbsp;as&nbsp;an&nbsp;extension&nbsp;method<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<br/>
</p>
</div>
</div>
</p>
<p>
Other examples follow (also using the <span class="inlinecode">data</span> element of an error specification, <a href="XsemanticsSyntax.html#ErrorSpecification" title="Go to &quot;Error Specification&quot;" >section ErrorSpecification</a>:
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;...<br/>
}<br/>
<span class="keyword">or</span><br/>
{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">fail</span><br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">error</span>&nbsp;<span class="string">"data&nbsp;from&nbsp;failure:&nbsp;"</span>&nbsp;+<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;previousFailure.getErrorInformations.head.getData<br/>
}<br/>
</p>
</div>
</div>
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">inject</span>&nbsp;<span class="keyword">extension</span>&nbsp;TraceUtils&nbsp;traceUtils<br/>
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...<br/>
&nbsp;&nbsp;&nbsp;&nbsp;}<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">or</span><br/>
&nbsp;&nbsp;&nbsp;&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;the&nbsp;failure&nbsp;we&apos;re&nbsp;interested&nbsp;in&nbsp;is&nbsp;the&nbsp;last&nbsp;one<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;we&nbsp;retrieve&nbsp;that&nbsp;using&nbsp;TraceUtils&nbsp;injected&nbsp;as&nbsp;extension<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">fail</span><br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">error</span>&nbsp;<span class="string">"data&nbsp;from&nbsp;failure:&nbsp;"</span>&nbsp;+<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;previousFailure.failureAsList.last.errorInformations.head.^data<br/>
&nbsp;&nbsp;&nbsp;&nbsp;}<br/>
</p>
</div>
</div>
</p>
<a name="StringRepresentation"></a>
<h3>String Representation</h3>
<p>
The classes generated by Xsemantics, and its runtime system, rely on
the class <a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/StringRepresentation.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.StringRepresentation" >StringRepresentation</abbr></a> for generating
a string corresponding to an object.  This will do its best to generate
a good string representation; in particular, if the object to represent
is an EObject which actually corresponds to a node in the model of the AST,
it will rely on <a class="jdoc" href="http://download.eclipse.org/modeling/tmf/xtext/javadoc/2.7/org/eclipse/xtext/nodemodel/util/NodeModelUtils.html" title="View JavaDoc"><abbr title="org.eclipse.xtext.nodemodel.util.NodeModelUtils" >NodeModelUtils</abbr></a> <a class="srcLink" href="https://github.com/eclipse/xtext/blob/v2.7.0/plugins/org.eclipse.xtext/src/org/eclipse/xtext/nodemodel/util/NodeModelUtils.java" title="View Source Code" >(src)</a> Xtext
class to use the string which corresponds to the object in the program.
</p>
<p>
However, you can bind your own implementation of <a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/StringRepresentation.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.StringRepresentation" >StringRepresentation</abbr></a>
in the runtime module 
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">public</span>&nbsp;Class&lt;?&nbsp;<span class="keyword">extends</span>&nbsp;StringRepresentation&gt;&nbsp;bindStringRepresentation()&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">return</span>&nbsp;MyDslStringRepresentation.<span class="keyword">class</span>;<br/>
}<br/>
</p>
</div>
</div>
</p>
<p>
In your custom implementation you can provide a string representation for the
classes of your model; <a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/StringRepresentation.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.StringRepresentation" >StringRepresentation</abbr></a> relies
on polymorphic dispatch, and you only need to implement methods <span class="inlinecode">stringRep</span>
for specific classes of your model (actually for any Java class), e.g.,
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">public</span>&nbsp;<span class="keyword">class</span>&nbsp;MyDslStringRepresentation&nbsp;<span class="keyword">extends</span>&nbsp;StringRepresentation&nbsp;{<br/>
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">protected</span>&nbsp;String&nbsp;stringRep(MyModelClass&nbsp;e)&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">return</span>&nbsp;e.getName();<br/>
&nbsp;&nbsp;&nbsp;&nbsp;}<br/>
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">protected</span>&nbsp;String&nbsp;stringRep(MyOtherModelClass&nbsp;e)&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">return</span>&nbsp;e.getFoo()&nbsp;+&nbsp;<span class="string">"&nbsp;-&nbsp;"</span>&nbsp;e.getBar();<br/>
&nbsp;&nbsp;&nbsp;&nbsp;}<br/>
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">protected</span>&nbsp;String&nbsp;stringRep(String&nbsp;s)&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">return</span>&nbsp;<span class="string">"&apos;"</span>&nbsp;+&nbsp;s&nbsp;+&nbsp;<span class="string">"&apos;"</span>;<br/>
&nbsp;&nbsp;&nbsp;&nbsp;}<br/>
}<br/>
</p>
</div>
</div>
</p>
<p>
Note that these methods are protected: if one needs to use 
<a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/StringRepresentation.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.StringRepresentation" >StringRepresentation</abbr></a> directly, this class
provides the public method <span class="inlinecode">String&nbsp;string(Object&nbsp;o)</span>.
</p>
<p>
In an Xsemantics system, you can get a string representation (through the
injected <a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/StringRepresentation.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.StringRepresentation" >StringRepresentation</abbr></a>) by simply
calling <span class="inlinecode">stringRep()</span>; this is useful for error specifications 
(<a href="XsemanticsSyntax.html#ErrorSpecification" title="Go to &quot;Error Specification&quot;" >section ErrorSpecification</a>), for instance
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">judgments</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;type&nbsp;|-&nbsp;EObject&nbsp;obj&nbsp;:&nbsp;<span class="keyword">output</span>&nbsp;EClassifier<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">error</span>&nbsp;<span class="string">"cannot&nbsp;type&nbsp;"</span>&nbsp;+&nbsp;stringRep(obj)<br/>
}<br/>
</p>
</div>
</div>
</p>
<a name="GetAll"></a>
<h3>Graph Closures (getAll)</h3>
<p>
Typically, in a DSL, when performing checks or interpretation, we need to
follow recursively a certain feature (e.g., <span class="inlinecode">superType</span> of
an entity in the domain model example); however, 
the AST for an Xtext language might be a graph due to references,
and thus it might contain cycles (without implying that the program is incorrect).
Thus, such recursive inspection of the graph might lead to an infinite loop. 
In a manual Java implementation we thus would have to keep track of the visited
nodes while inspecting the graph (to compute the <em>closure</em> of the graph).
</p>
<p>
To compute the ``closure&apos;&apos; of a graph, Xsemantics provides a predefined function
which allows to collect nodes in a graph according to EMF features avoiding
loops:
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
getAll(eObject,&nbsp;feature&nbsp;to&nbsp;collect,&nbsp;feature&nbsp;to&nbsp;follow,&nbsp;expected&nbsp;type)<br/>
</p>
</div>
</div>
</p>
<p>
An invocation of <span class="inlinecode">getAll</span> will return a list of ``expected
type&apos;&apos;, built by collecting all the elements from ``feature to collect&apos;&apos; of the
specified ``eObject&apos;&apos;, and recursively collecting such elements by following the
feature ``feature to follow&apos;&apos;, but avoid possible loops in the EMF graph
representing the AST.
</p>
<p>
An example of use of this predefined function can be found in
<a href="FJ-example.html#FJTyping" title="Go to &quot;Typing FJ Expressions&quot;" >section FJTyping</a>.
</p>
<a name="Auxiliary"></a>
<h2>Auxiliary Functions</h2>
<p>
Before declaring judgments, one can also declare some auxiliary
function signatures (<em>auxiliary descriptions</em>), which have the following shape:
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="comment">//&nbsp;auxiliary&nbsp;descriptions<br/>
</span><span class="keyword">auxiliary</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;myFun(&lt;parameters&gt;)&nbsp;:&nbsp;&lt;returntype&gt;<br/>
&nbsp;&nbsp;&nbsp;&nbsp;myFun2(&lt;parameters&gt;)&nbsp;<span class="comment">/*&nbsp;no&nbsp;return&nbsp;type&nbsp;*/</span><br/>
}<br/>
</p>
</div>
</div>
</p>
<p>
Then, before defining the rules for your system, you can specify
auxiliary function implementations for the corresponding
auxiliary descriptions.
</p>
<p>
In an auxiliary function definition the return type must not be declared
(the one specified in the corresponding auxiliary description will be used).
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="comment">//&nbsp;auxiliary&nbsp;functions&nbsp;examples<br/>
</span><span class="keyword">auxiliary</span>&nbsp;myFun(EObject&nbsp;o,&nbsp;String&nbsp;s)&nbsp;{&nbsp;...&nbsp;}<br/>
<span class="keyword">auxiliary</span>&nbsp;myFun(EClass&nbsp;o,&nbsp;String&nbsp;s)&nbsp;{&nbsp;...&nbsp;}<br/>
</p>
</div>
</div>
</p>
<p>
The things that make an auxiliary function belong to a specific auxiliary
description are the name and
the types of the parameters, which must be (Java) subtypes of the
corresponding types of the description (or exactly the same Java types).
Two auxiliary functions belonging to the same description 
must differ for at least one parameter&apos;s type.
</p>
<p>
The body of an auxiliary function uses the same syntax of rule premises
(<a href="XsemanticsSyntax.html#Premises" title="Go to &quot;Premises&quot;" >section Premises</a>).
</p>
<p>
An auxiliary function can then be called in premises as a standard
Java method.
</p>
<p>
Auxiliary functions are used in the FJ example (<a href="FJ-example.html#FJTypeSystem" title="Go to &quot;FJ Type System&quot;" >section FJTypeSystem</a>).
</p>
<a name="CheckRules"></a>
<h2>Rules for Validator: checkrule</h2>
<p>
In a Xsemantics system you can also write special rules, <em>checkrule</em>s, which
do not belong to any judgment, and are then used to generate <span class="inlinecode">@Check</span> methods
of the generated Java validator.
</p>
<p>
Such rules are of the shape
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">checkrule</span>&nbsp;RuleName&nbsp;<span class="keyword">for</span><br/>
&nbsp;&nbsp;&nbsp;&nbsp;JavaType&nbsp;objectToCheck<br/>
<span class="keyword">from</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;premises<br/>
</span>}<br/>
</p>
</div>
</div>
</p>
<p>
The <span class="inlinecode">from</span> block is just the same as in standard rules, but remember
that these check rules do not receive any rule environment.
</p>
<p>
Xsemantics will generate a Java validator with a <span class="inlinecode">@Check</span> method for each
<span class="inlinecode">checkrule</span> (see also <a href="XsemanticsSyntax.html#GeneratedValidator" title="Go to &quot;The Generated Java Validator&quot;" >section GeneratedValidator</a>);
just like in Java validator for Xtext languages, you can have
many <span class="inlinecode">checkrule</span>s for the same JavaType (provided the rule name is unique).
</p>
<a name="SystemExtension"></a>
<h2>Extend another System</h2>
<p>
When defyining a system it is also possible to <em>extend</em> another
Xsemantics system, using <span class="inlinecode"><span class="keyword">extends</span></span> followed by
the fully qualified name of the system to extend.
For instance, given this system
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">system</span>&nbsp;my.test.System<br/>
<br/>
<span class="keyword">import</span>&nbsp;org.eclipse.emf.ecore.*<br/>
<span class="keyword">import</span>&nbsp;java.util.*<br/>
<br/>
<span class="keyword">judgments</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;type&nbsp;|-&nbsp;EObject&nbsp;obj&nbsp;:&nbsp;<span class="keyword">output</span>&nbsp;EClassifier<br/>
&nbsp;&nbsp;&nbsp;&nbsp;subtype&nbsp;|-&nbsp;EObject&nbsp;left&nbsp;&lt;:&nbsp;EObject&nbsp;right<br/>
&nbsp;&nbsp;&nbsp;&nbsp;interpret&nbsp;|-&nbsp;EObject&nbsp;exp&nbsp;~&gt;&nbsp;<span class="keyword">output</span>&nbsp;EObject<br/>
}<br/>
<br/>
<span class="keyword">axiom</span>&nbsp;EObjectType<br/>
&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;EObject&nbsp;obj&nbsp;:&nbsp;obj.eClass<br/>
</p>
</div>
</div>
</p>
<p>
one can specify another system in terms of this one:
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">system</span>&nbsp;my.test.ExtendedSystem&nbsp;<span class="keyword">extends</span>&nbsp;my.test.System<br/>
<br/>
...<br/>
</p>
</div>
</div>
</p>
<p>
An extended system implicitly <em>inherits</em> from the <em>super</em> system
all judgments and rules (and check rules).
</p>
<p>
In the extended system one can <span class="inlinecode"><span class="keyword">override</span></span> a judgment and
any rules and check rules; in all cases the name and the kind of the redefined
element must be the same.  An axiom in a super system can be turned into
a rule in the extended system and vice versa.
</p>
<p>
If in an extended system we try to declare a judgment, rule, checkrule
with the same name of the ones present in the super system, without
<span class="inlinecode"><span class="keyword">override</span></span>, we will get an error.
</p>
<p>
For instance, we can override a judgment of the super system changing the
names of parameters and error specifications; similarly for rules and check
rules (and provide a different implementation):
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">system</span>&nbsp;my.test.ExtendedSystem&nbsp;<span class="keyword">extends</span>&nbsp;my.test.System<br/>
<br/>
<span class="keyword">import</span>&nbsp;org.eclipse.emf.ecore.*<br/>
<span class="keyword">import</span>&nbsp;java.util.*<br/>
<br/>
<span class="keyword">judgments</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;we&nbsp;override&nbsp;with&nbsp;different&nbsp;param&nbsp;name&nbsp;and&nbsp;error&nbsp;specification<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">override</span>&nbsp;type&nbsp;|-&nbsp;EObject&nbsp;eObject&nbsp;:&nbsp;<span class="keyword">output</span>&nbsp;EClassifier<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">error</span>&nbsp;<span class="string">"cannot&nbsp;type"</span><br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">source</span>&nbsp;eObject<br/>
}<br/>
<br/>
<span class="comment">//&nbsp;we&nbsp;override&nbsp;the&nbsp;axiom&nbsp;in&nbsp;the&nbsp;supersystem<br/>
</span><span class="comment">//&nbsp;and&nbsp;turn&nbsp;it&nbsp;into&nbsp;a&nbsp;rule&nbsp;with&nbsp;premises<br/>
</span><span class="keyword">override</span>&nbsp;<span class="keyword">rule</span>&nbsp;EObjectType<br/>
&nbsp;&nbsp;&nbsp;&nbsp;G&nbsp;|-&nbsp;EObject&nbsp;o&nbsp;:&nbsp;o.eClass<br/>
<span class="keyword">from</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;some&nbsp;premises<br/>
</span>}<br/>
</p>
</div>
</div>
</p>
<p>
An example of system extension will be shown in
<a href="Expressions-example.html#MoreInvolvedExpressionsSystem" title="Go to &quot;A more involved Expressions System&quot;" >section MoreInvolvedExpressionsSystem</a>.
</p>
<a name="CodeGeneration"></a>
<h2>Generated Code</h2>
<p>
Xsemantics will generate two Java classes for each xsemantics system:
</p>
<p>
<ul>
	<li>
		A Java class with the same name of the system, containing
			all the implementations of the system&apos;s rules and auxiliary functions;
	</li>
	<li>
		A <a class="jdoc" href="http://download.eclipse.org/modeling/tmf/xtext/javadoc/2.7/org/eclipse/xtext/validation/AbstractDeclarativeValidator.html" title="View JavaDoc"><abbr title="org.eclipse.xtext.validation.AbstractDeclarativeValidator" >AbstractDeclarativeValidator</abbr></a> <a class="srcLink" href="https://github.com/eclipse/xtext/blob/v2.7.0/plugins/org.eclipse.xtext/src/org/eclipse/xtext/validation/AbstractDeclarativeValidator.java" title="View Source Code" >(src)</a>
			subclass,
			with the same name of the system with suffix <span class="inlinecode">Validator</span> 
			(in particular, if the
			<span class="inlinecode"><span class="keyword">validatorExtends</span></span> clause, <a href="XsemanticsSyntax.html#validatorExtends" title="Go to &quot;The validatorExtends clause&quot;" >section validatorExtends</a>,
			is not used,
			then the generated validator inherits from 
			<a class="jdoc" href="http://download.eclipse.org/modeling/tmf/xtext/javadoc/2.7/org/eclipse/xtext/validation/AbstractDeclarativeValidator.html" title="View JavaDoc"><abbr title="org.eclipse.xtext.validation.AbstractDeclarativeValidator" >AbstractDeclarativeValidator</abbr></a> <a class="srcLink" href="https://github.com/eclipse/xtext/blob/v2.7.0/plugins/org.eclipse.xtext/src/org/eclipse/xtext/validation/AbstractDeclarativeValidator.java" title="View Source Code" >(src)</a>,
			otherwise it will inherit from the one specified with <span class="inlinecode"><span class="keyword">validatorExtends</span></span>) ; 
	</li>
</ul>
</p>
<p>
The generated classes rely on Google injection, so you must not
instantiate them directly, but only via injection.
</p>
<p>
Note that the Java code generated by Xsemantics will depend only
on the plugin <span class="inlinecode">org.eclipse.xsemantics.runtime</span>.  Thus, in case you want to deploy
your Xtext language implemented making use of Xsemantics, your language will
not need to depend on the whole Xsemantics SDK.
</p>
<a name="GeneratedPackage"></a>
<h3>The Generated Java Packages</h3>
<p>
Xsemantics will generate the Java classes into Java packages according to
the fully qualified name specified for your system.
</p>
<p>
For example, given this system fully qualified name
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">system</span>&nbsp;org.eclipse.xsemantics.example.fj.typing.FjTypeSystem<br/>
</p>
</div>
</div>
</p>
<p>
The generated Java class for the rule system (<a href="XsemanticsSyntax.html#GeneratedSystem" title="Go to &quot;The Generated Java Rule System&quot;" >section GeneratedSystem</a>) will
be generated in the Java package <span class="inlinecode">org.eclipse.xsemantics.example.fj.typing</span> and
the generated Java validator (<a href="XsemanticsSyntax.html#GeneratedValidator" title="Go to &quot;The Generated Java Validator&quot;" >section GeneratedValidator</a>) will be generated in the
package <span class="inlinecode">org.eclipse.xsemantics.example.fj.typing.validation</span>.
</p>
<p>
If you plan to reuse these Java classes in other Eclipse projects
(e.g., in the UI project or in the test project), please make sure to
export such Java packages in the MANIFEST.MF.
</p>
<a name="GeneratedSystem"></a>
<h3>The Generated Java Rule System</h3>
<p>
The generated Java class containing the rules of your system will have
public methods for the judgments and auxiliary functions of your system.
For instance, if you have
</p>
<p>
<ul>
	<li>
		a judgment called <em>myjudgment</em>
	</li>
	<li>
		which takes two input parameters of Java types <em>MyClass1</em> and <em>MyClass2</em>
	</li>
	<li>
		and an output parameter of Java type <em>MyOutputClass</em>
	</li>
</ul>
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">judgments</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;myjudgment&nbsp;|-&nbsp;MyClass1&nbsp;arg1&nbsp;:&nbsp;MyClass2&nbsp;arg2&nbsp;:&nbsp;<span class="keyword">output</span>&nbsp;MyOutputClass<br/>
}<br/>
</p>
</div>
</div>
</p>
<p>
the generated Java system will feature three public methods
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">public</span>&nbsp;Result&lt;MyOutputClass&gt;&nbsp;myjudgment(MyClass1&nbsp;arg1,&nbsp;MyClass2&nbsp;arg2)<br/>
<span class="keyword">public</span>&nbsp;Result&lt;MyOutputClass&gt;&nbsp;myjudgment(RuleEnvironment&nbsp;env,<br/>
&nbsp;&nbsp;&nbsp;&nbsp;MyClass1&nbsp;arg1,&nbsp;MyClass2&nbsp;arg2)<br/>
<span class="keyword">public</span>&nbsp;Result&lt;MyOutputClass&gt;&nbsp;myjudgment(<br/>
&nbsp;&nbsp;&nbsp;&nbsp;RuleEnvironment&nbsp;env,&nbsp;RuleApplication&nbsp;trace,<br/>
&nbsp;&nbsp;&nbsp;&nbsp;MyClass1&nbsp;arg1,&nbsp;MyClass2&nbsp;arg2)<br/>
</p>
</div>
</div>
</p>
<p>
The class <a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/Result.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.Result" >Result</abbr></a> is part of Xsemantics runtime,
and it is a wrapper for the actual result value (that can be retrieved
with method <span class="inlinecode">getValue()</span>) and a possible failure
(in the shape of a <a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/RuleFailedException.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.RuleFailedException" >RuleFailedException</abbr></a>).
</p>
<p>
A similar generation patterns is used for auxiliary descriptions
(but the returned type will NOT be wrapped into a 
<a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/Result.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.Result" >Result</abbr></a> and 
<a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/RuleFailedException.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.RuleFailedException" >RuleFailedException</abbr></a> is declared to be thrown).
</p>
<p>
The value in the result will be <span class="inlinecode">null</span> if the judgment rule failed;
in that case you might want to inspect the <a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/RuleFailedException.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.RuleFailedException" >RuleFailedException</abbr></a>.
In particular, you might want to use the utility methods of
<a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/TraceUtils.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.TraceUtils" >TraceUtils</abbr></a> to get the stack of all
the rule failures (also already formatted as an indented string).
</p>
<p>
In case the judgment has two output parameters, the class
<a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/Result2.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.Result2" >Result2</abbr></a> will be used which acts as a pair
(thus the two values can be obtained with methods <span class="inlinecode">getFirst()</span> and
<span class="inlinecode">getSecond()</span>, respectively); similarly for three output
parameters, <a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/Result3.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.Result3" >Result3</abbr></a> (with the
additional method <span class="inlinecode">getThird()</span>).
</p>
<p>
If the judgment has no output parameter (<em>predicate judgment</em>), the type of the result will
be <a class="jdoc" href="http://docs.oracle.com/javase/8/docs/api/java/lang/Boolean.html" title="View JavaDoc"><abbr title="java.lang.Boolean" >Boolean</abbr></a>, i.e., <span class="inlinecode">Result&lt;Boolean&gt;</span>.
</p>
<p>
For such judgments some additional utility methods are generated, which
allow you to just check whether the predicate succeded
(in case of failures you have no additional information; but if you
pass a trace you can still inspect how the judgment succeded).
For instance, consider this predicate judgment
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">judgments</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;mypredjudgment&nbsp;|-&nbsp;MyClass1&nbsp;arg1&nbsp;:&nbsp;MyClass2&nbsp;arg2&nbsp;<br/>
}<br/>
</p>
</div>
</div>
</p>
<p>
the generated Java system will feature three additional public methods
(note the suffix "Succeded"):
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="comment">//&nbsp;same&nbsp;generated&nbsp;methods&nbsp;as&nbsp;before,&nbsp;plus:<br/>
</span><span class="keyword">public</span>&nbsp;Boolean&nbsp;myjudgmentSucceeded(MyClass1&nbsp;arg1,&nbsp;MyClass2&nbsp;arg2)<br/>
<span class="keyword">public</span>&nbsp;Boolean&nbsp;myjudgmentSucceeded(RuleEnvironment&nbsp;env,<br/>
&nbsp;&nbsp;&nbsp;&nbsp;MyClass1&nbsp;arg1,&nbsp;MyClass2&nbsp;arg2)<br/>
<span class="keyword">public</span>&nbsp;Boolean&nbsp;myjudgmentSucceeded(<br/>
&nbsp;&nbsp;&nbsp;&nbsp;RuleEnvironment&nbsp;env,&nbsp;RuleApplication&nbsp;trace,<br/>
&nbsp;&nbsp;&nbsp;&nbsp;MyClass1&nbsp;arg1,&nbsp;MyClass2&nbsp;arg2)<br/>
</p>
</div>
</div>
</p>
<p>
The first generated method basically only takes the arguments specified in the
judgment.  With the second version, you can also pass an environment
(generated Java code can transparently deal with null environments).
The third one is useful for testing/debugging purposes: if you pass
an instance of <a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/RuleApplicationTrace.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.RuleApplicationTrace" >RuleApplicationTrace</abbr></a> if the
method terminates with success you can then inspect the trace of all the rules
invoked together with the values used in the rules.  If the judgment fails,
you will see also the rules that failed in the rule application trace.
By using the method <span class="inlinecode">traceAsString(RuleApplicationTrace)</span> of
<a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/TraceUtils.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.TraceUtils" >TraceUtils</abbr></a> you will have a string representation
indented, with the following idea
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
final&nbsp;result&nbsp;provided&nbsp;by&nbsp;rule&nbsp;MyRule<br/>
&nbsp;rule&nbsp;1&nbsp;used&nbsp;by&nbsp;MyRule&nbsp;to&nbsp;get&nbsp;to&nbsp;the&nbsp;result<br/>
&nbsp;&nbsp;rule&nbsp;2&nbsp;used&nbsp;by&nbsp;rule&nbsp;1<br/>
&nbsp;&nbsp;&nbsp;rule&nbsp;3&nbsp;used&nbsp;by&nbsp;rule&nbsp;2<br/>
&nbsp;&nbsp;&nbsp;...<br/>
&nbsp;rule&nbsp;1a&nbsp;used&nbsp;by&nbsp;MyRule&nbsp;to&nbsp;get&nbsp;to&nbsp;the&nbsp;result<br/>
&nbsp;&nbsp;rule&nbsp;2a&nbsp;used&nbsp;by&nbsp;rule&nbsp;1a<br/>
&nbsp;&nbsp;...<br/>
</p>
</div>
</div>
</p>
<p>
An example of usage of traces is shown in <a href="Expressions-example.html#ExpressionsCodeGeneration" title="Go to &quot;Generation for Expressions&quot;" >section ExpressionsCodeGeneration</a>
for the Expressions language example.
</p>
<p>
The generated Java system will contain also <em>issue codes</em> (as public string
constants) that will be used by the generated validator when a rule fails.
This can be useful to then implement quickfixes for specific failures.
</p>
<a name="GeneratedValidator"></a>
<h3>The Generated Java Validator</h3>
<p>
From a system definition Xsemantics also generates a Java
class (which extends <a class="jdoc" href="http://download.eclipse.org/modeling/tmf/xtext/javadoc/2.7/org/eclipse/xtext/validation/AbstractDeclarativeValidator.html" title="View JavaDoc"><abbr title="org.eclipse.xtext.validation.AbstractDeclarativeValidator" >AbstractDeclarativeValidator</abbr></a> <a class="srcLink" href="https://github.com/eclipse/xtext/blob/v2.7.0/plugins/org.eclipse.xtext/src/org/eclipse/xtext/validation/AbstractDeclarativeValidator.java" title="View Source Code" >(src)</a>).
If you plan to use this generated validator, because you defined
some <em>checkrule</em>s (<a href="XsemanticsSyntax.html#CheckRules" title="Go to &quot;Rules for Validator: checkrule&quot;" >section CheckRules</a>), it is better to specify
the <span class="inlinecode"><span class="keyword">validatorExtends</span></span> clause in order to have
a validator which extends the validator that Xtext generated for you
in the <span class="inlinecode">src-gen</span> folder.
This is detailed in <a href="XsemanticsSyntax.html#validatorExtends" title="Go to &quot;The validatorExtends clause&quot;" >section validatorExtends</a>.  If this clause is not
specified, using the generated validator requires some more work,
as detaild in <a href="XsemanticsSyntax.html#withoutValidatorExtends" title="Go to &quot;Without the validatorExtends clause&quot;" >section withoutValidatorExtends</a>.
</p>
<a name="validatorExtends"></a>
<h4>The validatorExtends clause</h4>
<p>
Recently, the
<span class="inlinecode"><span class="keyword">validatorExtends</span></span> clause was introduced in order
to specify the base class of the generated validator.
Using this clause (right after the <span class="inlinecode"><span class="keyword">system</span></span> definition),
the generated validator will be already easily usable: all that remains
to do is to modify your DSL validator in your <span class="inlinecode">src</span> folder
so that it extends the validator by Xsemantics.
</p>
<p>
Note that <span class="inlinecode"><span class="keyword">validatorExtends</span></span> cannot be used
together with system extension (<a href="XsemanticsSyntax.html#SystemExtension" title="Go to &quot;Extend another System&quot;" >section SystemExtension</a>): in case of
system extension, the generated validator will automatically extend
the generated validator of the super system.
</p>
<p>
The <span class="inlinecode"><span class="keyword">validatorExtends</span></span> clause requires a
<a class="jdoc" href="http://download.eclipse.org/modeling/tmf/xtext/javadoc/2.7/org/eclipse/xtext/validation/AbstractDeclarativeValidator.html" title="View JavaDoc"><abbr title="org.eclipse.xtext.validation.AbstractDeclarativeValidator" >AbstractDeclarativeValidator</abbr></a> <a class="srcLink" href="https://github.com/eclipse/xtext/blob/v2.7.0/plugins/org.eclipse.xtext/src/org/eclipse/xtext/validation/AbstractDeclarativeValidator.java" title="View Source Code" >(src)</a>
subclass (the content assist will filter completions accordingly).
The class which should be specified is the class which Xtext
generated for you in the <span class="inlinecode">src-gen</span> folder
(which should be of the shape <span class="inlinecode">AbstractMyDslJavaValidator</span>).
Then, the validator class in the <span class="inlinecode">src</span> folder should be modified
so that it extends the validator class generated by Xsemantics.
</p>
<p>
For instance, if your validator initially looks like:
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">public</span>&nbsp;<span class="keyword">class</span>&nbsp;MyDslJavaValidator&nbsp;<span class="keyword">extends</span>&nbsp;AbstractMyDslJavaValidator&nbsp;{<br/>
</p>
</div>
</div>
</p>
<p>
In your system definition you should specify
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">system</span>&nbsp;org.my.dsl.MyDslSemantics<br/>
<br/>
<span class="keyword">validatorExtends</span>&nbsp;org.my.dsl.validation.AbstractMyDslJavaValidator<br/>
</p>
</div>
</div>
</p>
<p>
And then, your original Java validator (in the <span class="inlinecode">src</span> folder)
should be modified so that it
extends the validator generated by Xsemantics:
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">public</span>&nbsp;<span class="keyword">class</span>&nbsp;MyDslJavaValidator&nbsp;<span class="keyword">extends</span>&nbsp;MyDslSemanticsValidator&nbsp;{<br/>
</p>
</div>
</div>
</p>
<p>
The examples described in <a href="Expressions-example.html#Expressions" title="Go to &quot;An Expression Language&quot;" >section Expressions</a> and in
<a href="Lambda-example.html#Lambda" title="Go to &quot;Lambda&quot;" >section Lambda</a> use the <span class="inlinecode"><span class="keyword">validatorExtends</span></span> clause.
</p>
<a name="withoutValidatorExtends"></a>
<h4>Without the validatorExtends clause</h4>
<p>
If the
<span class="inlinecode"><span class="keyword">validatorExtends</span></span> clause is not used in the
Xsemantics system definition,
the validator generated by Xsemantics cannot be used (i.e., injected) directly, 
since it does
not implement the method <span class="inlinecode">getEPackages</span>; so, considering the project
you have just created, the advised way of using it is to copy the <span class="inlinecode">getEPackages</span>
from the abstract validator generated by Xtext, e.g., <span class="inlinecode">AbstractMyDslJavaValidator</span>,
into your <span class="inlinecode">MyDslJavaValidator</span>, and then make your validator inherit
from the validator generated by Xsemantics, e.g., <span class="inlinecode">MyDslSystemValidator</span>.
Summarizing, for this example your validator should look like this:
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">public</span>&nbsp;<span class="keyword">class</span>&nbsp;MyDslJavaValidator&nbsp;<span class="keyword">extends</span>&nbsp;MyDslSystemValidator&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="comment">//&nbsp;copied&nbsp;from&nbsp;AbstractMyDslJavaValidator<br/>
</span>&nbsp;&nbsp;&nbsp;&nbsp;@Override<br/>
&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">protected</span>&nbsp;List&lt;EPackage&gt;&nbsp;getEPackages()&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;List&lt;EPackage&gt;&nbsp;result&nbsp;=&nbsp;<span class="keyword">new</span>&nbsp;ArrayList&lt;EPackage&gt;();<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;result.add(org.xtext.example.mydsl.myDsl.MyDslPackage.eINSTANCE);<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">return</span>&nbsp;result;<br/>
&nbsp;&nbsp;&nbsp;&nbsp;}<br/>
}<br/>
</p>
</div>
</div>
</p>
<p>
The example described in <a href="FJ-example.html#FJ" title="Go to &quot;Featherweight Java&quot;" >section FJ</a> uses this technique.
</p>
<p>
A better way to use the generated validator is to rely on the
<span class="inlinecode"><span class="keyword">validatorExtends</span></span> clause as detailed in <a href="XsemanticsSyntax.html#validatorExtends" title="Go to &quot;The validatorExtends clause&quot;" >section validatorExtends</a>.
</p>
<a name="ErrorGeneration"></a>
<h3>Error Marker Generation</h3>
<p>
The generated Java validator will also automatically generate error markers
in case the corresponding rule invocations fail.  Error markers will be generated
according to the error information found in the trace of a failure
(which is contained in a <a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/RuleFailedException.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.RuleFailedException" >RuleFailedException</abbr></a>).
</p>
<p>
When generating error markers the validator will use only the error information
that related to an <a class="jdoc" href="http://download.eclipse.org/modeling/emf/emf/javadoc/2.10.0/org/eclipse/emf/ecore/EObject.html" title="View JavaDoc"><abbr title="org.eclipse.emf.ecore.EObject" >EObject</abbr></a> <a class="srcLink" href="https://github.com/eclipse/emf/blob/R2_9_0/plugins/org.eclipse.emf.ecore/src/org/eclipse/emf/ecore/EObject.java" title="View Source Code" >(src)</a> which corresponds to
an actual node in the AST.  Note that this error information can be customized in
a Xsemantics system by explicit error specifications (see <a href="XsemanticsSyntax.html#ErrorSpecification" title="Go to &quot;Error Specification&quot;" >section ErrorSpecification</a>
and <a href="XsemanticsSyntax.html#ExplicitFailure" title="Go to &quot;Explicit Failure&quot;" >section ExplicitFailure</a>), thus, you should keep in mind the above strategy when
using <span class="inlinecode">source</span> (and <span class="inlinecode">feature</span>) in an error specification.
</p>
<p>
Furthermore, the validator will not use ALL the error information referring
to nodes in the AST: by default it will use the inner most error information
referring to an actual node in the AST.  This corresponds to using the error
of the first rule invocation that failed, and this is usually what actually
is important for generating an error.
</p>
<p>
For instance, if you consider the example of expressions (<a href="Expressions-example.html#Expressions" title="Go to &quot;An Expression Language&quot;" >section Expressions</a>)
and the following expression which cannot be typed
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
i&nbsp;=&nbsp;(1&nbsp;+&nbsp;5)&nbsp;-&nbsp;(10&nbsp;*&nbsp;true)<br/>
</p>
</div>
</div>
</p>
<p>
the generated validator will generated an error marker to the inner most
subexpression which made the typing failed, i.e., <span class="inlinecode">10&nbsp;*&nbsp;true</span>.
</p>
<p>
Remember that in an error specification (see <a href="XsemanticsSyntax.html#ErrorSpecification" title="Go to &quot;Error Specification&quot;" >section ErrorSpecification</a>) you can
also specify the <span class="inlinecode">feature</span> for error generation, and in that case the
validator will use also the specified feature for generating the error marker.
</p>
<p>
The generated validator relies on an injected <a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/validation/XsemanticsValidatorFilter.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.validation.XsemanticsValidatorFilter" >XsemanticsValidatorFilter</abbr></a>
to filter the error information according to the strategy defined above;
you can customize the filtering by injecting your implementation.
The filter relies on <a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/TraceUtils.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.TraceUtils" >TraceUtils</abbr></a> which
provides many utility methods to access the error trace.
An example of customization is shown in <a href="Lambda-example.html#LambdaCustomization" title="Go to &quot;Customizations for Lambda&quot;" >section LambdaCustomization</a>.
</p>
<p>
If one needs the full control on how error markers are generated,
a custom <a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/validation/XsemanticsValidatorErrorGenerator.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.validation.XsemanticsValidatorErrorGenerator" >XsemanticsValidatorErrorGenerator</abbr></a>
can be injected.
</p>
<a name="Caching"></a>
<h2>Automatic Caching</h2>
<p>
The automatic caching mechanism has been introduced in version 1.5.0
(it can be seen as an experimental feature).
</p>
<p>
Xsemantics provides automatic caching mechanisms that can
be enabled in a system specification. The interface for Xsemantics
cache is <a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/XsemanticsCache.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.XsemanticsCache" >XsemanticsCache</abbr></a>.
</p>
<p>
The default implementation of this interface,
<a class="jdoc" href="http://help.eclipse.org/helios/topic/org.eclipse.platform.doc.isv/reference/api/org/eclipse/xsemantics/runtime/XsemanticsCacheDefaultImpl.html" title="View JavaDoc"><abbr title="org.eclipse.xsemantics.runtime.XsemanticsCacheDefaultImpl" >XsemanticsCacheDefaultImpl</abbr></a>
uses internally
the class <a class="jdoc" href="http://download.eclipse.org/modeling/tmf/xtext/javadoc/2.7/org/eclipse/xtext/util/OnChangeEvictingCache.html" title="View JavaDoc"><abbr title="org.eclipse.xtext.util.OnChangeEvictingCache" >OnChangeEvictingCache</abbr></a> <a class="srcLink" href="https://github.com/eclipse/xtext/blob/v2.7.0/plugins/org.eclipse.xtext.util/src/org/eclipse/xtext/util/OnChangeEvictingCache.java" title="View Source Code" >(src)</a> that is part
of the Xtext utility library. This class implements a cache that
stores its values in the scope of a resource. The values will be
automatically discarded as soon as the contents of the resource
changes semantically.
</p>
<p>
When caching is enabled in Xsemantics system specification,
then Xsemantics will generated Java code that automatically
uses the cache.
caching is enabled on a per-judgment and per-auxiliary description basis, 
using the keyword <span class="inlinecode"><span class="keyword">cached</span></span>. 
Note that by default
caching is based on the Java hashing features, thus it makes sense
only when used with actual object instances, not with references.
It is responsibility
of the programmer to be aware of which judgments and auxiliary
functions to cache, depending on the nature of the involved input
parameters.
</p>
<p>
You can specify also a boolean <span class="inlinecode"><span class="keyword">condition</span></span> to enable
caching only when such condition holds.  For judgments, it is also possible
to specify whether generated methods (<a href="XsemanticsSyntax.html#GeneratedSystem" title="Go to &quot;The Generated Java Rule System&quot;" >section GeneratedSystem</a>) for judgments
should be cached as well (otherwise caching is enabled only for the methods of
the single rules).
</p>
<p>
This is an example using all these features.
</p>
<p>
<div class="literallayout">
<div class="incode">
<p class="code">
<span class="keyword">auxiliary</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;eclasses(EObject&nbsp;o)&nbsp;:&nbsp;List&lt;EClass&gt;&nbsp;<span class="keyword">cached</span><br/>
&nbsp;&nbsp;&nbsp;&nbsp;auxnocacheentryPoints(EObject&nbsp;o)&nbsp;:&nbsp;Boolean&nbsp;<span class="keyword">cached</span>&nbsp;{&nbsp;<span class="keyword">condition</span>=(!(o&nbsp;<span class="keyword">instanceof</span>&nbsp;EClass))&nbsp;}<br/>
}<br/>
<br/>
<span class="keyword">judgments</span>&nbsp;{<br/>
&nbsp;&nbsp;&nbsp;&nbsp;type&nbsp;|-&nbsp;EObject&nbsp;o&nbsp;:&nbsp;<span class="keyword">output</span>&nbsp;EClass&nbsp;<span class="keyword">cached</span><br/>
&nbsp;&nbsp;&nbsp;&nbsp;nocacheentryPoints&nbsp;||-&nbsp;EObject&nbsp;o&nbsp;:&nbsp;<span class="keyword">output</span>&nbsp;EClass&nbsp;<span class="keyword">cached</span>&nbsp;{&nbsp;<span class="keyword">entryPoints</span>=NONE&nbsp;}<br/>
&nbsp;&nbsp;&nbsp;&nbsp;withCacheCondition&nbsp;|=&nbsp;EObject&nbsp;o&nbsp;:&nbsp;<span class="keyword">output</span>&nbsp;EClass&nbsp;<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">cached</span>&nbsp;{&nbsp;<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">condition</span>&nbsp;=&nbsp;(!environment.isEmpty()&nbsp;&amp;&amp;&nbsp;!(o&nbsp;<span class="keyword">instanceof</span>&nbsp;EClass))<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<br/>
&nbsp;&nbsp;&nbsp;&nbsp;withCacheConditionBlock&nbsp;|=&nbsp;EObject&nbsp;o&nbsp;:&gt;&nbsp;<span class="keyword">output</span>&nbsp;EClass&nbsp;<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">cached</span>&nbsp;{&nbsp;<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span class="keyword">condition</span>&nbsp;=&nbsp;{&nbsp;(!environment.isEmpty()&nbsp;&amp;&amp;&nbsp;!(o&nbsp;<span class="keyword">instanceof</span>&nbsp;EClass))&nbsp;}<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}<br/>
}<br/>
</p>
</div>
</div>
</p>
<p>
Xsemantics also ships with a version of FJ (see <a href="FJ-example.html#FJ" title="Go to &quot;Featherweight Java&quot;" >section FJ</a>) where caching is enabled.
This is actually implemented as a separate example (<em>fjcached</em>), which is an
extension of the original FJ example (This is also another example of system extension, <a href="XsemanticsSyntax.html#SystemExtension" title="Go to &quot;Extend another System&quot;" >section SystemExtension</a>).
</p>
</body>
</html>
